Previously, in the integer parsing functions, it only processed the word if it identified the necessity for it by checking for the presence of tsep. Now you are always doing it. For me, this doesn't seem necessary.

I think the performance of code you said would be better.

However, even if there is no tsep, processing such as skipping whitespaces is necessary, so various string processing logic before and after must be reverted as before.

If I have to, I also think about that maybe it would be better to use copy_string_without_char like before.

So instead of sacrificing a little bit of performance, I think it is reasonable the current version of consolidating and simplifying logic.

However, I'm not an expert, so I’d appreciate your advice. If you still think it’s better to make the change even after considering what I said, I’ll follow your recommendation.

However, even if there is no tsep, processing such as skipping whitespaces is necessary,

I honestly don't see much problem in having the repeated logic of dealing with leading and trailing whitespace as it was before.

If I have to, I also think about that maybe it would be better to use copy_string_without_char like before.

Considering the goal of the issue was to create a superset of this function, I think it's better to use the function that you are rewriting.

So instead of sacrificing a little bit of performance, I think it is reasonable the current version of consolidating and simplifying logic.

This is a valid point. I am ambivalent about this. I would wait for @WillAyd opinion on this topic.

This overall seems pretty complicated - what didn't work with strtok?

If _str_copy_decimal_str_c only needed to skip whitespaces, I would have used strtok.
However, the function’s requirements are more complex:

• it needs to skip certain character sets selectively,
• handle different token types (tsep, decimal, digits), and
• avoid modifying the source string (since strtok removes delimiters).

I initially experimented with using strtok just for whitespace skipping, but it only made the code deeper and harder to follow.
Using it to simplify more complex parsing turned out to be difficult — at least with my current approach.

Also, because strtok modifies the input string, I would have needed to make a copy first to avoid side effects.
(I’m not entirely sure how critical those side effects are in this context, but I chose to take the conservative route.)

For these reasons, I decided to use strspn and memcpy instead.
Up until commit 7b0be60, the code remained relatively simple, but after adding repetitive safety checks (such as buffer overflow prevention), it evolved into its current form.